home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Pascal Super Library
/
Pascal Super Library (CW International)(1997).bin
/
LIBRARY
/
PBLIB1
/
PUBLIB01.TXT
< prev
next >
Wrap
Text File
|
1994-05-01
|
4KB
|
95 lines
Pascal Public Domain Library Specifications
This is simply my current thoughts and something to start arguing from.
Howard Richoux
1. Licensing - Free to ALL, commercial and personal use. The only
restriction is to require code source credit as appropriate.
Copyright retained by who?
2. Target users: Borland Pascal version 7, real mode. Should wind up
TP6 compatible with little effort. Will need help to assure
protected mode compatibility. How about BPW?
3. Suggested structure: Until a better model is presented, I suggest the
following:
level 1 - one or more large TPUs containing general purpose, minimum
global routines. Rely on linker to trim out un-referenced code and
data. Use SYSTEM unit only, CRT adds a big chunk. "Hello world"
program should be virtually unaffected by a uses of a level 1 unit.
Use minimum of calls of other level 1 routines.
level 2 - routines and objects referencing level 1 support. Try for
minimum cross referencing of level 2 structures and code.
level 3 - a single call might bring in 10s of K of code and or data
from lower levels. Separate TPUs by functional area CRT, SOUND,
SPEECH, ...
level 4 - references commercial or otherwise restricted code.
Requirements need to be spelled out.
4. Criteria for inclusion:
- Nearly anything which is used more than once belongs in a library.
- Resource use should be commensurate with benefits. Large functions
need to be broken down so that the compiler can trim out unused
code and data.
5. Coding standards. A lot of this is personal taste and habits, but
some standardization is necessary to make it easy to code from
memory rather than have to constantly refer to documentation. I
keep finding inconsistancies in my own naming schemes, but I have
found it best to fix them when detected rather than be faced with
a much larger job down the road.
External standards - I expect we should prefix every procedure and
function name with something like Pb (for Public) to make it
obvious where to look. I like having the last portion of the
name indicate Function return type (like PbBooleanStr returning
results as a string).
Internal standards - Much tougher. I have a personal bias against
code that looks like a snake:
xxxxxx
xxxx
xxx
xxxx
xxxx
xxx
and I like:
If xxxxx then
begin
yyyy
end;
I suspect that others will disagree violently. This is a discussion
point.
6. Utility programs
One of the keys to standards is the tools provided to support them. It would
not be unreasonable to provide a program lister that could convert back and
forth between styles. I have most of a "ChangeAll" program so I can change
names easily. The USES utility helps resolve unit problems. TMAP has been
very useful to me in turning TP map files into something that makes sense. the
trouble is that about 5% of the information is either missing from the map
file, or I just am interpreting it wrong. UNITSCAN builds a .dbf file of
function and procedure names and a specific type of comment, from the interface
section of a unit source file. It has limitations, but can be useful. By
incorporating {section xxxx } type comments in the source files, I can use
TPRINT to extract specific sections (such as interface info) into documents
directly from the source code. SORTSECT can re-arrange the segments into
alphabetical order.
All of these utilities are 95% or so of what they really ought to be. They
work, but have some minor unreasonable limitations. Documentation is minimal -
I wrote them so I should know how they work (ha ha). With a little work,
they could form the basis of a workable development environment.
One of my other little utilities is TP, my substitute for the IDE. This is
not ready for prime time, but it lets me work the way I want to. Someone
else can re-program it totally differently if they choose.